1. Field of the Invention
The present invention relates generally to printer printing processes, more particularly to generating high resolution alphanumeric characters, and more specifically to a method for generating high resolution text in printer drivers irrespective of operating system kernal mode Device Drive Interface ("DDI"), commands for text resolution.
2. Description of Related Art
Computer application programs are written and provided to the end-user for the solution of specific problems or to perform specific actions. Many applications programs are capable of producing hard copy printout commands. As examples, there are word processing software for producing documents, software programs for specific reports such as spreadsheets for accounting, software applications for updating specific files or databases, and the like.
FIG. 1 (Prior Art) shows a typical example of a common scheme for generating alphanumeric text. Application programs 101 generally provide very simple, generic-type, instructions for generating text over the Application Programming Interface, or "API". For example, if a word in a box is desired from a word processing program, the API instruction simply provides instructions such as: EQU "SQUARE(n.sub.1, n.sub.2, n.sub.3, n.sub.4) EQU TEXT(`word`)".
In turn, API codes are defined and provided by a developer of computer operating systems programs, or "O/S," 103 to the application program developers as essential entry points into the operating system software. The O/S is a set of master programs and routines resident in a computer which guides the computer in the performance of its tasks, and assists the applications programs with certain, predefined support functions; exemplary state of the art operating systems are DOS, WINDOWS and WINDOWS NT.TM. software. Application programs are packaged, for example, as a "DOS Version" or a "Windows Version," indicating which O/S compatibility is provided. In the generation of text, the O/S takes API instructions and generates elaborate code instructions for a device driver interface, or "DDI" (where there may be hundreds of DDI code instructions for each API instruction). For example, in a Windows O/S, Microsoft has supplied a graphical device interface, or "GDI," component 104. The GDI 104 routines are the video screen manager program for any personal computer using the Windows O/S; GDI knows how to draw almost anything and brokers the commands between the application 101 and a hard copy device driver code 105. The DDI provides entry points into the driver code 105 used by the O/S provider. A hard copy apparatus supplier's driver code 105 essentially repackages DDI code instructions into a specific format--e.g., PostScript.TM. fontware commands--which are then used to actually print each character. Hard copy apparatus manufacturers provide specific apparatus driver code 105, generally proprietary or conforming to an industry standard, for translating the DDI instructions into a form which will give the proper output from the writing instrument--e.g., an ink-jet pen--by the printing apparatus' 107 rendering firmware. The rendering firmware converts the specific format instructions to simple, digital PRINT/NO PRINT dot matrix commands and the dots are printed accordingly on a print medium 109 at a rendered resolution. [Note also that the O/S developer may also suggest "Normal Printer Driver " commands and modes as part of the O/S kernel operations which the driver code developer can implement to ensure compatibility between the driver code and the O/S.]
In order to be compatible with any and all application program software providers, an O/S has substantially rigid kernel programs--programs that form the most essential instructions. The kernel formatting is provided by the O/S developer to the application software developers and device driver developers to ensure compatibility. In the case of printing text, the elaborate DDI instructions are generally kernal mode components. For efficient printing and enhanced printing, however, use of kernel program instructions is not practical. In other words, as the kernel mode components are essentially an extension of the O/S, access is extremely limited and carefully controlled by the O/S. Moreover, even when allowed, customization of an O/S kernel mode component for every character capable of being printed is overly expensive in terms of real time operation and extensive memory capacity requirements. Thus, to be compatible with an O/S program such as the WindowsNT O/S, the applications provider conforms to a standard resolution--e.g., three hundred dots-per-inch by three hundred dots-per-inch (300 dpi.times.300 dpi)--also referred to hereinafter as the reported resolution. That is, in the WindowsNT printing model, printer drivers need to report a single, square, resolution in the beginning of a command set and all text and graphics are designed to be rendered at that conventional, fixed, reported resolution.
A problem with this convention is that the writing instruments, such as ink-jet pens manufactured by Hewlett-Packard Company, assignee herein, are capable of printing alphanumeric text characters at much higher resolution than that used as a standard by operating systems. Thus, the reporting of standard single resolution is too simplistic for an HP.TM. ink-jet pen that is capable of printing black text at a much higher resolution than color graphics. Moreover, with HP ink-jet pens, the resolution need not be the same in the x-axis (pen scan) and the y-axis (paper translation), which can enhance text presentation by non-square printing. However, even were the host application and O/S capable of generating reported resolution data equal to a higher resolution to match the capability of the high quality text writing instrument, the amount of data transmitted over the input-output output buffer printing path would require a much larger memory in the hard copy apparatus than is economical for the original equipment manufacturer to build in for the average end-user. Additionally, a reporting resolution greater than 300 dpi.times.300 dpi would slow down the time to print a single page to an unacceptably slow rate for the average desired text quality. At the same time, compared to color printing, there is a desire for improvement of print quality to a visual level that is achieved only in greater than 300 dpi.times.300 dpi resolution. Improving print quality without slowing throughput or increasing product costs provides contradictory design objectives for the system engineer. Therefore, there is a need to generate text in more than one resolution--namely, above the O/S kernel mode reporting structure--in order to achieve highest quality alphanumeric character rendering while still maintaining compatibility with the O/S.
One solution is to report the highest resolution supported by the printer hardware and receive both text and graphics at this very high resolution. Then, black text data is processed as is but graphics data is sub-sampled to lower the resolution to the actual supported hardware color printing capability. This technique demands high data traffic and a large memory capability to modify kernal mode instructions.
Another solution is to report the lowest resolution supported by the printer, process the color graphics as is but upscale black text data using additional text rendering software. In other words, once the inaccessible hard copy device driver routines are established, post-driver image processing of data must be employed to improve print quality. This post-drive image processing generally is either a fast but less than satisfactory simple solution, such as a doubling of received reported resolution data and printing at double the reported resolution, or the use of complex and slower image processing programs known as resolution enhancement techniques ("RET"). As the font size shrinks, e.g., in lengthy, often used, contract forms reduced to one page for ease of use, simple data doubling techniques are not useful. Alphanumeric character RET image processing programs have limited success in improving the quality of scaled text, particularly if the resolution is non-square. The RET solutions often require large memories to store look-up tables ("LUT").
Thus, there is a need for a method of generating high resolution alphanumeric characters in the highest resolution supported by the hardware without resort to customization of kernal mode instructions.